IBIS Macromodel Task Group Meeting date: 09 August 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Jared James Google: Zhiping Yang Intel: * Michael Mirmak * Kinger Cai * Chi-te Chen Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara * Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 26th meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. -------------- New Discussion: Proposal for a new keyword: [Clock Group] Michael reviewed the [Clock Group] BIRD draft he had recently emailed to the ATM list. He said this proposal was intended to address a shortcoming of [Clock Pins] in the context of a DDR controller. Michael recalled that BIRD208 added the [Clock Pins] keyword in IBIS 7.1. The purpose was to inform EDA tools about the "clocking relationship" between two pins. For example, it enables the model maker to tell the tool or user that one pin clocks data into another. He said a hole in the scheme had been discovered. For DDR, one might find there are many different clocking relationships. One DRAM IC might have 4 data lines strobed by a single clock. Another variant of the IC might have 8 data lines strobed by the same clock. Even if the two designs were nearly identical otherwise, this could be handled by using separate [Component] definition. However, for a DDR controller, this presents more of a problem. A single DDR controller might be configurable to support x4 or x8 DRAMs (note: not in the same simulation, but configurable ahead of time). Having to create multiple [Component]s to support the same controller would be clumsy and inefficient. The new proposal would add a [Clock Group]/[End Clock Group] keyword pair. The pair encapsulates a [Clock Pins] keyword and enables a clock group name to be specified for that particular instance. Multiple [Clock Group] pairs could be specified in the same [Component] to allow multiple uniquely named instances of [Clock Pins] to be provided. The clock group name entries would be used in the same way as a [Model Selector] and allow EDA tools to present users with a list of [Clock Pins] options from which to select. Michael said that overall the proposal was very simple. There is no change at all to existing usage of [Clock Pins]. This merely adds an additional level of hierarchy to specify multiple named configurations. Walter said he understood the motivation for this proposal. He observed that the fundamental issue was that we had previously created the concept of a "group" as a configuration selector, for example, [Interconnect Model Group]s, [Model Selector]s, etc. He said he would probably support this proposal too, but he suggested an alternate possibility. He said that instead of adding a new group keyword every time we need one, we might consider an #ifdef style syntax. With #ifdef style syntax a configuration file could be provided to define which portions of the model were used. He said this might be a more general way to handle the issue. Michael said he would be willing to consider the idea of #ifdefs. Michael noted that the [Clock Group] proposal would make [Clock Pins] the first keyword that could appear at two different levels in the hierarchy. [Clock Pins] could then appear directly under [Component], or it could appear inside a [Clock Group]/[End Clock Group]. Arpad said that to be consistent with other group keywords, the [Clock Pins] themselves should be named (and multiple instances allowed), and the names would then be listed in the [Clock Group]. Michael agreed and said that would have been his first choice. However, he had been concerned that it would be more trouble to modify an existing keyword's definition. However, he was open to the suggestion. Bob asked if Michael's intention was to get this included in IBIS 7.2. Michael said that would be ideal, but he acknowledged that the proposal was new and not quite ready for consideration. He said he would not push to have it included in IBIS 7.2. Arpad said Walter's #ifdef proposal was interesting. He asked: If we were to add #ifdef would we want to rewrite existing [Model Selector] and group selector keyword sections to use the #ifdef style? Walter said we wouldn't need to touch the existing keywords at all. Dual-Input AMI Model Questions: Michael shared a presentation, "Questions on Creating Clocked (Dual-Input) Rx AMI Models." It presented a flow chart of an EDA tool's parsing/analysis flow for a clock-forwarded IBIS-AMI Rx model. Michael thought there might be the possibility of ambiguities. Michael observed that an EDA tool now has to parse all the way down [Model]-> [Algorithmic Model]->.ami file->Rx_Use_Clock_Input, to determine if a particular model is a dual input model. Therefore, it must parse to that level and have the [Clock Pins] keyword provided in order to understand the pin-level connectivity. Michael presented an example (slide 5) in which the [Clock Pins] keyword was provided and both the pins (clock pin and clocked pin) on one line were defined (via the [Pin] keyword) to use the same dual input Rx AMI model. He expressed concern that this might imply that a single instance of the model handled both pins. Walter and others said no, if an AMI model is specified for each pin, then each pin gets its own instance, even if the same [Model] is specified for both pins. Randy noted one other special case. It would be possible to specify no AMI model for the clock pin at all. In that case, only the AMI model for the data pin is instantiated, and the EDA tool is expected to provide a pass-through model for the clock pin that passes its waveform data directly into the clock_times input of the data model. He noted that this would be legal only if "Times" was not amongst the list of possible values for Rx_Use_Clock_Input specified in the data model's .ami file. Michael asked whether his example scenario would require him to create different [Model]s for the clock and data pins in order to specify different AMI models. Walter said that strictly speaking, the answer was no. He said the same AMI model could be specified for both pins, and at simulation time the user would select different configurations for each pin. For example, the user would set Rx_Use_Clock_Input to "None" for the clock model, and they would set Rx_Use_Clock_Input to "Times" for the data pin. Randy said this would be an extremely cumbersome and confusing way to distribute the models. He said such a model would likely support equalization for the data pin, and the user would have to shut all of that off for the clock pin, for example. Walter agreed that this would not be the recommended way to create and distribute the model. He said Michael had proposed a corner case example, and he was merely stating that it is possible to handle that case without changes to IBIS. Walter, Randy, and others agreed that even if the underlying implementation of the executable model were the same for both the clock and data pins, it would be much better to provide different [Model]s for the two pins so the .ami file for each would be configured for proper operation of the respective pins. Arpad asked Michael if he was insisting on using the same [Model] for the clock and data pins. Michael said he was not. He was asking if we needed to clarify things for model makers. Michael commented that the introduction of the Rx_Use_Clock_Input effectively turns all AMI_GetWave functions into dual input models, and the value "None" is the special case that specifies legacy single-input operation. Walter agreed, but clarified that the model has to be written to handle dual input operation, and Rx_Use_Clock_Input (if it exists) advertises what the model is capable of. Walter said he didn't think we needed to add anything to the specification to clarify things for model makers. Michael said he would send his slides to the ATM list. He asked that people consider how an example setup of his scenario would work for the "Wave" case only. He said he wanted to make sure we hadn't missed anything. - Randy: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Michael to send his Dual Input Rx Questions presentation to the ATM list. ------------- Next meeting: 16 August 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives